Two flakes in client_spec.rb, both shared-CI app state, neither an
SDK bug:

1. queries-users: before(:all) seeds Frodo / Sam / Gandalf / Legolas
   and hard-deletes them in after(:all). When a CI run dies before
   the after(:all) fires, leftovers stay on the shared app and the
   next run's queries-users test (race=Hobbit, length==2) picks up
   sediment.

   Fix:
   - Extract cleanup into a cleanup_fellowship_leftovers!(client)
     helper, called from a dedicated before(:all) block so the
     concern is separate from the fellowship setup.
   - Keep the per-run unique race tag as defensive isolation for
     concurrent runs racing the cleanup -> upsert window.

2. custom commands create -> get / update / delete: backend write is
   eventually consistent; the read-side regularly hits
   'the command "<uuid>" does not exist'.

   Fix: add an RSpec block matcher

     expect { ... }.to eventually(matches?(value))

   with chainable .with_retries(n) / .every(seconds). Replace the
   custom-commands loop_times calls with this matcher so the read-side
   reads as an eventual-consistency contract instead of a retry loop.

The existing loop_times helper stays as a backward-compat alias
delegating to a plain  block helper, so other tests that
use it keep working untouched.

The default rspec progress (dots) hides which test is in flight when a
runner stalls. Last week's CI on Ruby 3.4 spent 41 minutes silently
between two examples — the log only shows DEPRECATION warnings before
and after, so the culprit was unidentifiable.

Adds .rspec config (--format documentation, --profile 25) and a
support/timing.rb hook that warns:

  [timing] start <full description>
  [timing] N.NN s <pass|fail> <full description>

on each example. Two effects:

* A hung runner now leaves a 'start ...' breadcrumb so the next person
  knows exactly which spec was mid-flight.
* End-of-run --profile output lists the 25 slowest, which surfaces the
  flake culprits without having to scan the whole transcript.